Simulation management system

ABSTRACT

A method, apparatus and program product oversee and coordinate the automatic generation, monitoring and submission of package files and other modeling processes to enable focused, flexible and efficient modeling of design performance characteristics.

CROSS-REFERENCE TO RELATED APPLICATION

This application is related to the concurrently filed U.S. PatentApplication entitled “Electronic Circuit Design Analysis System.” Theentire disclosure of that U.S. patent application is incorporated intothis application by reference.

FIELD OF THE INVENTION

The present invention relates generally to computer operations andapplications, and more particularly, to the automatic design andperformance analysis of computer systems.

BACKGROUND OF THE INVENTION

Advances in the field of computer and electronic system design continueto drive and facilitate greater processing efficiencies. Throughmodeling and other analysis, electronic files containing designs forelectronic circuits and computer systems are optimized for use astemplates for hardware manufacturing and networking. A typicalcomputer/circuit design file includes text that accounts for numerouselectronic hardware components. For example, a file containing a designcommonly includes programmatic objects and identifiers descriptive ofbusses, microchips, expansion cards and other system hardware. A busgenerally enables selective communication between a computer processorunit (CPU) and one or more components, such as those mounted on anexpansion card. A typical bus, such as a Peripheral ComponentInterconnect or Industry Standard Architecture bus, may additionallycouple to a main system circuit board. Expansion cards are typicallythin, rectangular printed circuit boards that have connector pins alongone edge that couple to corresponding sockets of the bus. Programmaticobjects describing such components within the design file may includedelay, routing, voltage, resistance, symbol and/or other parameter data.

In operation, actual components of a circuit cooperate to processelectronic signals according to system requirements. More particularly,the components interconnect to generate and communicate electronicsignals. Different combinations and configurations of components affectsystem performance. For example, component layout can impact systemtiming. System timing regards the arrival of a signal at a givencomponent within a predetermined window of time. Each component visitedalong the path of a signal introduces varying delay that affects thetime required for the signal to reach a destination component. Thus,successful timing requires coordination with other signals and signalpaths to ensure coordinated system processing. Failure to achievedesired timing can result in processing delays, error and failure. Forinstance, a system function that conjunctively processes multiplesignals cannot complete its processing until the last of the signalsarrives. Thus, the function can be unduly delayed or altogetherfrustrated should an unacceptable amount of time lapse while waiting forthe last of the signals to arrive. For example, delays may cause raceconditions, where a process may shutdown altogether in response to alate signal.

Another performance factor affected by system design is noise. Noise ischaracterized as static or interference introduced as the signal travelsthrough system components and connections. As such, the electricalcharacteristics of the signal change as it propagates through a system.For instance, square wave characteristics of an input signal may becomeless distinct due to loss dispersion encountered in a system. While sometolerance of noise is typically built into a system designspecification, unacceptable noise levels can severely impact signalclarity and system performance. For example, data may become corrupted,e.g., a binary “1” may register as a “0.”

Production of a hardware system represents a substantial investment ofmaterial, manpower and other economic resources. Consequently, it isadvantageous to verify design integrity prior to committing it tohardware. More particularly, it is desirable to predict or otherwiseanalyze performance characteristics of a design prior to implementation.To this end, simulation programs, or engines, have been developed tomodel performance of the programmatic objects of a design. Such modelingpractices help to assure conformity with system needs.

Processes associated with modeling, however, represent a substantialinvestment of manpower, as a single modeling effort may require days ofpreparation, constant monitoring and technical attention. For instance,an analyst must attempt to create a data file that encapsulates criticalaspects of a design, yet is small enough to be processed withoutoverwhelming the memory and processing resources of a system.Furthermore, the analyst must ensure that the data file, as well allprograms required to process the file, are accounted for, available andrecalled at the proper sequences, or an entire simulation may becompromised. In that vein, the analyst must also ensure that an adequateamount of processing power and memory is available to accommodate amodeling process. Failure to provide such files and resources on atimely basis can unduly delay and frustrate a modeling process. Forexample, an analyst may painstakingly manage a modeling process forweeks before realizing that the absence of a missing file or adequatememory will require the entire modeling process to be re-accomplished.Moreover and as may be inferred from above, modeling requires manydedicated hours from the most highly skilled and experienced analysts toproperly setup, coordinate, monitor and otherwise execute a simulation.Such demands on personnel complicate training, limit the number of thoseavailable who can execute a modeling scenario, and draw the most skilledpersonnel away from other projects that could otherwise benefit fromtheir expertise.

Consequently, and for in part the above delineated reasons, there existsa need for an improved manner of managing a circuit system simulation.

SUMMARY OF THE INVENTION

The present invention provides a flexible, automated and otherwiseimproved apparatus, method and program product for managing andautomating a simulation useful in analyzing performance of an electroniccircuit in a manner that addresses the above-identified problems ofexisting systems. In one respect, embodiments of the present inventionmay automatically generate and/or access, as well as monitor andotherwise manage, data and programs required for the simulation. Forthese purposes, data consistent with the invention may includelogically-linked package files. The package files comprise abstracteddata that is small enough to allow reasonable processing, but stillsufficient to model a performance characteristic of an electricaldesign. The package files and other applications are automatically andselectively included within a given simulation. To this end, a profilecomprising user input flexibly calls only those applications required inthe simulation, further reducing processing and memory requirements.

Data generation, retrieval, and monitoring processes consistent with thepresent invention may be automated, realizing even greater efficienciesand accountability, while reducing analyst workload and requiredexpertise. For instance, an embodiment in accordance with the presentinvention may coordinate sending batch jobs, mitigating the possibilityof race conditions. Another program consistent with the principles ofthe invention may monitor a simulation in parallel for a statuscondition, the detection of which sets in motion a remedial actiondesigned to address the condition. Automated pre-run checks may reduceincidents where a simulation is begun with faulty or missingdata/resources, and a searchable log file may be automaticallymaintained for accountability and analysis purposes. The flexibleembodiments of the present invention may be altered or interruptedduring the course of a simulation in response to user input, which maybe converted automatically into a profile. Where desired, post processesin accordance with the present invention may automatically free up filespace and other memory after a simulation's completion.

By virtue of the foregoing there is thus provided an improved simulationmanagement mechanism that addresses shortcomings of conventionaltechniques. These and other objects and advantages of the presentinvention shall be made apparent in the accompanying drawings and thedescription thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate an embodiment of the inventionand, together with a general description of the invention given above,and the detailed description of the embodiment given below, serve toexplain the principles of the invention.

FIG. 1 is a block diagram of a client-server computer system havingsoftware consistent with the invention.

FIG. 2 is a block diagram of an electrical circuit design suited foranalysis using the computer system of FIG. 1.

FIG. 3 is a flowchart having method steps for automatically managinganalysis of an electrical circuit design consistent with the inventionand suited for execution within the system of FIG. 1.

FIG. 4 is a flowchart having method steps consistent with the inventionand having particular application within the context of the datageneration and coordination processes of FIG. 3.

FIG. 5 is a flowchart having method steps consistent with the inventionand having particular application within the context of the automaticpackage file generation processes of FIG. 4.

FIG. 6 is a flowchart having method steps consistent with the inventionand having particular application within the context of the package/netfile stitching and model creation processes of FIG. 4.

DETAILED DESCRIPTION OF DRAWINGS

With reference generally to the embodiment of FIG. 1, there is shown asystem 10 configured to automatically and flexibly manage analysis of anelectronic design file. In so doing, the system 10 may, among otherfunctions, initiate, oversee and automate simulations useful indetermining a desired performance parameter, to include timing and noisecharacteristics. In one respect, the processes of the system 10 mayselectively and automatically generate and combine appropriate packagefiles needed to analyze a desired performance parameter. For purposes ofthis specification, a package file may include code descriptive ofand/or relating to a portion of an electrical design to be analyzed. Forinstance, a package file may comprise text that programmatically definesa component, or group of components and connections that affect a pathtraveled by a signal for a given application.

According to an embodiment that is consistent with the invention,selected package files may be automatically generated, retrieved andlogically linked (stitched) using reference connections defined withineach package file to form a composite, net file. An exemplary referenceconnection may include geometric coordinates of a pin connection used tointerconnect components. As disclosed more particularly in the U.S.Patent Application entitled “Electronic Circuit Simulation System,”which is submitted concurrently by the same applicants and herebyincorporated by reference in its entirety, a package file comprises dataabstracted from a design file. The package files may be logically-linkedto efficiently model critical functionality of the a circuit designfile. The amount of abstracted data is small enough to allow reasonableprocessing, but is still sufficient to model a desired performancecharacteristic.

Despite the processing efficiencies of package techniques, it has beenfound that modeling can still be a painstaking, error prone andmeticulous process. For example, while the relatively smaller sizes ofthe package files greatly reduce the volume of data to be processed, atypical modeling session may still require analysis of over 20,000 nets.Furthermore, modeling still represents a substantial investment ofmanpower, as a single modeling effort may require hours to days ofconstant monitoring. For instance and as discussed herein, an analystmust ensure that required programs and files are accounted for andrecalled at the proper sequences, or an entire simulation may becompromised. Analysts must furthermore ensure that an adequate amount ofprocessing power and memory is available to accommodate a modelingprocess. Failure to provide such files and resources on a timely basiscan unduly delay and frustrate a modeling process.

To address these challenges, generation of the net files and otherapplications are constantly monitored and coordinated by the processesof the present invention. For purposes of this specification, anapplication, or modeling application, may comprise one or more of anycomputer resources, to include programs, processors, data, memory and/orhardware ports, among others. Such monitoring allows potential problemsto be addressed preemptively. Processes consistent with the inventionfurther automate retrieval, coordination and submission of data andprograms for execution.

FIG. 1 illustrates a system 10 implemented as a client-server basedcomputer system. System 10 includes at least one apparatus, e.g., one ormore client computers 12 and one or more server computers 14. For thepurposes of the invention, each computer 12, 14 may representpractically any type of computer, computer system or other programmableelectronic device capable of functioning as a client and/or server in aclient-server environment. Moreover, each computer 12, 14 may beimplemented using one or more networked computers, e.g., in a cluster orother distributed computing system. Moreover, as is common in manyclient-server systems, multiple client computers 12 will typically beinterfaced with a given server computer 14. While more capable computersystems may present advantages in certain embodiments consistent withthe principles of the present invention, a suitable server 14 forpurposes of this specification may comprise any device configured toreceive and process an electronic message transmitted from the clientcomputer 12.

Client computer 12 typically includes a central processing unit 16including at least one microprocessor coupled to a memory 18, which mayrepresent the random access memory (RAM) devices comprising the mainstorage of computer 12, as well as any supplemental levels of memory,e.g., cache memories, non-volatile or backup memories (e.g.,programmable or flash memories), read-only memories, etc. “Memory” forpurposes of this entire specification should be further be construed toinclude file space, such as that associated with a hard drive. Examplesof stored programs stored within memory 18 may include a stitchingprogram 42 configured to retrieve and link appropriate package filesaccording to a system configuration file 57. As described below ingreater detail, another program 62 may process a system design file 46to derive physical, logical and electrical files 48, 50 and 52,respectively. A design tool 60, such as a computer aided design (CAD)program, may be used to generate the design file 46. A filter program 64of the system 10 may determine what information should will be includedwithin a package per operating and user specifications. A status program53 may include instructions configured to give realtime updates to auser and/or log. A sequencer 47 may coordinate processing of dependentjobs, while a pre-run check program 49 verifies that needed resourcesare available for a given simulation. A pre-process program initiatesgeneration of needed resources, such as package files 44. In addition,memory 18 may be considered to include memory storage physically locatedelsewhere in computer 12, e.g., any cache memory in a processor in CPU16, as well as any storage capacity used as a virtual memory, e.g., asstored on a mass storage device 20 or on another computer coupled tocomputer 12.

Computer 12 also typically receives a number of inputs and outputs forcommunicating information externally. For interface with a user oroperator, computer 12 typically includes a user interface 22incorporating one or more user input devices (e.g., a keyboard, a mouse,a trackball, a joystick, a touchpad, and/or a microphone, among others)and a display (e.g., a CRT monitor, an LCD display panel, and/or aspeaker, among others). Otherwise, user input may be received viaanother computer or terminal.

For additional storage, computer 12 may also include one or more massstorage devices 20, e.g., a floppy or other removable disk drive, a harddisk drive, a direct access storage device (DASD), an optical drive(e.g., a CD drive, a DVD drive, etc.), and/or a tape drive, amongothers. An exemplary mass storage may include a database 44 thatcontains package files generated from stored logical, physical andelectrical files 48, 50 and 52, respectively. As discussed in greaterdetail below, the system 10 may derive such files 48, 50 and 52 from asystem design file 46, shown at server computer 14 for exemplarypurposes. Still other examples of storage 20 may include a net database58 containing nets for recall and/or combination with other nets asneeded. Electrical model information may be retrieved from anotherdatabase 45 in response to instructions from a processed electrical file52. Where advantageous, the electrical data/file 52 may includeelectrical model information.

The database 44 may further include a user profile 41 that containspaths to desired executables. This profile 41 is similar to a globalprofile 43, which comprises default or administratively establishedpaths. The embodiment of FIG. 1 additionally includes a run profiler 55for facilitating generation and processing of profiles. In oneembodiment, the profiler 55 may include code for efficiently callingapplications. One of skill in the art will recognize that the inclusionand distribution of the databases, files and other stored data asbetween the client and server computers may be altered substantiallywhile still conforming with the principles of the present invention.

Furthermore, computer 12 may include an interface 24 with one or morenetworks (e.g., a LAN, a WAN, a wireless network, and/or the Internet,among others) to permit the communication of information with othercomputers and electronic devices. It should be appreciated that computer12 typically includes suitable analog and/or digital interfaces betweenCPU 16 and each of components 18, 20, 22 and 24 as is well known in theart.

Similar to computer 12, computer 14 includes a CPU 26, memory 28, massstorage 29, user interface 32 and network interface 34. However, giventhe nature of computers 12 and 14 as client and server, in manyinstances computer 14 will be implemented using a multi-user computersuch as a server computer, a midrange computer, a mainframe, etc., whilecomputer 12 will be implemented using a desktop or other single-usercomputer. As a result, the specifications of the CPU's, memories, massstorage, user interfaces and network interfaces will typically varybetween computers 12 and 14. However, one skilled in the art willappreciate that other hardware environments are contemplated within thecontext of the invention.

Computers 12, 14 are generally interfaced with one another via a network36, which may be public and/or private, wired and/or wireless, localand/or wide-area, etc. Moreover, network 36 may represent multiple,interconnected networks. In the illustrated embodiment, for example,network 36 may include the Internet.

Each computer 12, 14 operates under the control of an operating system38, 40 and executes or otherwise relies upon various computer softwareapplications, components, programs, objects, modules, data structures,etc. Moreover, various applications, components, programs, objects,modules, etc. may also execute on one or more processors in anothercomputer coupled to computer 12, 14 via a network, e.g., in adistributed or client-server computing environment, whereby theprocessing required to implement the functions of a computer program maybe allocated to multiple computers over a network.

In general, the routines executed to implement the embodiments of theinvention, whether implemented as part of an operating system or aspecific application, component, program, object, module or sequence ofinstructions, or even a subset thereof, will be referred to herein as“computer program code,” or simply “program code.” Program codetypically comprises one or more instructions that are resident atvarious times in various memory and storage devices in a computer, andthat, when read and executed by one or more processors in a computer,cause that computer to perform the steps necessary to execute steps orelements embodying the various aspects of the invention. For instance,the embodiment of FIG. 1 includes stitching program code 42 configuredto selectively link packages into net files as appropriate per ananalysis session. Complementary program code may reside on the server 14side, but one of skill in the art should appreciate that embodimentsconsistent with the principles of the present invention may nonethelessuse program code resident at only one, or any number of locations.

Moreover, while the invention has and hereinafter will be described inthe context of fully functioning computers and computer systems, thoseskilled in the art will appreciate that the various embodiments of theinvention are capable of being distributed as a program product in avariety of forms, and that the invention applies equally regardless ofthe particular type of signal bearing media used to actually carry outthe distribution. Examples of signal bearing media include but are notlimited to recordable type media such as volatile and non-volatilememory devices, floppy and other removable disks, hard disk drives,magnetic tape, optical disks (e.g., CD-ROMs, DVDs, etc.), among others,and transmission type media such as digital and analog communicationlinks.

In addition, various program code described hereinafter may beidentified based upon the application within which it is implemented ina specific embodiment of the invention. However, it should beappreciated that any particular program nomenclature that follows isused merely for convenience, and thus the invention should not belimited to use solely in any specific application identified and/orimplied by such nomenclature. Furthermore, given the typically endlessnumber of manners in which computer programs may be organized intoroutines, procedures, methods, modules, objects, and the like, as wellas the various manners in which program functionality may be allocatedamong various software layers that are resident within a typicalcomputer (e.g., operating systems, libraries, API's, applications,applets, etc.), it should be appreciated that the invention is notlimited to the specific organization and allocation of programfunctionality described herein.

Those skilled in the art will recognize that the exemplary environmentillustrated in FIG. 1 is not intended to limit the present invention.Indeed, those skilled in the art will recognize that other alternativehardware and/or software environments may be used without departing fromthe scope of the invention.

FIG. 2 shows an exemplary electrical circuit design 70 for which apackage 44 or net file 58 of FIG. 1 may be generated in accordance withthe principles of the present invention. The circuit 70 is shown forillustrative purposes only, and one of skill in the art will appreciatethat package and/or net files consistent with the invention may begenerated according to hardware environments that comprise much smalleror larger hardware entities. Suitable hardware applications may thusinclude, for example, the networked computer system 10 of FIG. 1 and/ora portion of a single microchip/driver 72 a of FIG. 2, to includetransistors on the chip 72 a.

As shown in FIG. 2, the circuit 70 designated for analysis includeshardware positioned along a signal path from a designated driver 72 a toa designated receiver 72 b. The driver 72 a comprises the point oforigination of a signal for purposes of a net modeling scenario, and thereceiver 72 b represents the point of the signal's arrival at itsdestination within the defined net file. As such, a net and/or packagemay comprise any hardware and/or software positioned along a pathbetween a driver and a receiver, A net may further comprise multiplepackages that each define a portion of a computer system. One of skillin the art will appreciate that typical package files are advantageouslydesigned to be of relatively manageable sizes. The driver 72 a of FIG. 2includes a microchip housed within a module 74 a. A typical microchipincludes components formed in silicon, such as capacitors, resistors,inductors, connectors and switches. While only one microchip is showndirectly connected to the module 74 a, one of skill in the art willnonetheless appreciate that a suitable module may alternatively mountmultiple microchips.

The driver 72 a connects to the module 74 a via a pin connector 73 aformed from silicon substrate, such as a Controlled Collapse Chip orflip-chip solder-bump connection as is known in the field. Similarly,the module 74 a attaches to an expansion card 78 a via another connector76 a. The expansion card 78 a includes a thin, rectangular printedcircuit board that has electrical components such as capacitors,inductors and resistors. The expansion card 78 a further includesconnector pins (not shown) along one edge that couple to correspondingsockets (not shown) of a main system circuit board 84 and/or a bus 82 a.The bus 82 a generally enables selective communication between themicrochip 72 a and (a processor communicating with) the main systemboard 84. A signal may travel through each of these and other componentsof the electrical circuit design 70 along a path to the receiver 72 bdefined by line 80. Of note, the microchip/receiver 72 b attaches to amodule 74 b and the rest of the electrical circuit design 70 (asprogrammatically defined within the net file) by connector pin 73 b. Asdiscussed herein, such pins 73 a&b may provide useful referenceconnections for purposes of stitching packages and other nets. As such,one of skill in the art should appreciate that the electrical circuitdesign 70 as defined in a net file may include multiple, stitchedpackage files. Accordingly, the electrical circuit design 70 may includemany more reference connectors as needed.

FIG. 3 is a flowchart 100 having process steps suitable for executionwithin the computer system 10 of FIG. 1. More particularly, theexemplary steps 102-136 automatically manage and execute a simulation ofa signal traveling in an electrical circuit 70 in accordance with theprinciples of the present invention. That is, the exemplary steps102-136 of FIG. 3 are suited to automatically initiate, oversee andautomate simulations useful in determining a desired performanceparameter, to include timing and noise characteristics.

Blocks 102-108 of FIG. 3 regard input from a user and/or administratorthat specifies desired performance aspects of the simulation. The userinput, or profile data, may comprise script files that contain paths ofexecution or instructions. The execution paths/instructions maydesignate a program, data source or other simulation application, suchas those shown in the exemplary system 10 of FIG. 1. The profile datathus provides users with a mechanism to flexibly tailor and specifyresources to be used and/or modeled within a given simulation. Wheredesired, a user-friendly interface may aid the user in converting userinput into properly formatted script. For example, such an interface mayinclude a drag-and-drop type interface and/or a pull-down menu option.

Turning more particularly blocks 102-108 of FIG. 3, the system 10 maydetermine at block 102 if one or more global profiles 43 exists. Aglobal profile 43 may comprise paths to or data indicative ofexecutables, program and simulation data. As such, the global profile 43may further comprise default settings that are retrieved at block 104.Where so desired, the user may select from one or more such globalprofiles 43. For example, the execution path of one global profile mayspecify the location of verified or shared data, while an analogous pathof another profile may be configured to call SANBOX or other workingdata. The same or another global profile may contain paths to localand/or remote sources, per user or administrator preferences. Theprofile at block 102 thus presents a platform from which desired datasources may be specified.

Similarly, the system 10 may retrieve and select one or more userprofiles 41 at block 104, if one or more such user profiles 41 arepresent and selected at block 106. User profiles 41 may comprise userspecified executable paths, and may preempt conflicting global profileinstructions. In a specific example, the user profile 41, like a globalprofile 43, may stipulate whether a particular function of a simulationshould execute locally or remotely. A remote application may beappropriate where multiple simulation functions are to be monitored by auser in parallel. Conversely, a local execution of a function mayfacilitate analysis where serial execution of simulation functions areinvolved As discussed, the user specified paths of the user profile 41will typically preempt those of a selected global profile 43. Thus, anembodiment of the present invention may allow a user to flexibly tailora simulation according to their own preferences.

In any case, the system 10 may read an applicable profile(s) at block108 and call programs, data and other applications associated with theprofile at block 110. Among others, such applications may include theexemplary software features discussed above in connection with FIG. 1.For example, the system 10 may specify logical and physical data used ina previous simulation. Such a scenario may have particular applicationwhere a user is optimizing system parameters using some repeatable data.

At block 112, the system 10 may execute a pre-run check to verify thatall or certain of the applications specified in the profile at block 108have been successfully retrieved. For instance, the system 10 maydetermine whether adequate processing power and memory space isavailable. Another pre-run check may include confirming that specifiedelectrical model and program files are accessible. A pre-run check may,but typically does not appraise or copiously evaluate the calledapplications. As such, the pre-run check can be accomplished relativelyquickly.

In addition to its speed, the pre-run check of block 112 may mitigateinstances where the absence of a needed application is discovered toolate in a simulation process to recover lost time and other resources.In the absence of such a feature, for instance, a simulation couldprogress for sixteen hours before ending prematurely as a result ofrunning out of temporary memory space. Instead, and by virtue of theembodiment shown in FIG. 3, the system may determine at block 112 whatamount of file space or other memory will be required for theapplication of the above example, and if that amount of memory isactually available at block 114. If not, then a user may be notified atblock 116 so sufficient memory may be allocated, for instance, prior tocontinuing with the application. Where appropriate, the remedial actionof block 116 may include other automated features, such as retryingaccess to a I/O port that failed on a first attempt. In any case, one ofskill in the art should appreciate that a suitable remedial action mayinclude any step taken in response to a determined status. The system 10thus contributes additional monitoring and management capabilities atblock 1 12.

Once the pre-run check has been accomplished at block 112 of FIG. 3, thesystem 10 may begin actual simulation processes at block 118. Whilediscussed below in greater detail in connection with FIG. 4, suchprocesses for purposes of the flowchart 100 of FIG. 3 may includecoordinating and otherwise managing data generation and modeling for asimulation. That is, the processes consistent with the invention maymanage modeling of the travel of a signal from a driver to a receiver.Such simulations concerning the net file may be accomplished accordingto any known modeling technique. Thus, features of the present inventionmay apply to and enhance conventional modeling practices and mechanisms.

A monitoring component of the management processes consistent with theinvention may include the generation and output of realtime statisticsat block 120. Exemplary realtime statistics may comprise messages orother data configured to apprize a user of ongoing simulation processes.While some realtime statistics may be routine or confirming in nature,others may indicate a need for direct user intervention. For instance, arealtime statistic may notify a user that an error has occurred at block122. An error message, for example, may inform the user that a neededjob is idle or otherwise inaccessible. Such notification at block 122may enable the user to correct or otherwise account for a detectedanomaly at block 116 of FIG. 3. That is, a user may attempt to enablememory, processors, executable paths, permissions or other resourcesneeded to address a detected error as the simulation processes continueto the extent possible.

Other and/or the same statistics of an embodiment that is consistentwith the principles of the present invention may be automaticallyrecorded in a system log or other memory at block 124. As with therealtime statistics discussed in connection with block 122, the type andfrequency of statistics stored in the log at block 124 may be customizedby a user. Such tailored storage may assist the user in precisely andefficiently evaluating simulation processes per applicationspecifications. Where desired, the log file may comprise a searchablefile compiled and consolidated from a number of other log files.

At any time during the processes of the present invention, a user or thesystem 10 may pause, or interrupt, system activities. As with all otherprocesses described herein, the interrupted processes at block 126 maybe selectively affected without interrupting other processes that theuser may wish to continue. Additionally, as with all other steps of theflowcharts of FIGS. 3-6, step 124 may be augmented, omitted orrearranged in relation to other steps while remaining consistent withthe underlying principles of the present invention. As represented atblock 128 of FIG. 3, the state of an interrupted process may be saved ina register or other memory. Saving the state at block 128 permits theprocess to be recalled and resumed at the same point at which it wasinterrupted.

The system 10 may automatically assemble desired output at block 130.Such output may include the results of multiple, parallel processes thatmay be selectively assembled at block 130 for the purpose of outputtinga report at block 132. A typical report output at block 132 may includedata relating to noise and/or timing information. That is, exemplaryoutput of a simulation may include one or more waveforms at block 132.The program code 69 may be configured to then determine a desiredcharacteristic from the waveform. For instance, the program code 69 maydetermine noise characteristics and/or timing information at block 132from an analog waveform. Noise determinations may regard predictedstatic, signal interference or loss dispersion encountered as a signaltravels through design components and connections. Timing regards thearrival of a signal at a given component within a predetermined windowof time. While such performance factors may be of particular interest tosystem designers of one application, one of skill in the art willappreciate that other modeling characteristics may alternatively and/oradditionally be output by analyzing waveforms output at block 132 inaccordance with the principles of the present invention. In any case,reports reflecting such analysis may be stored at block 132 for futureuse, to include comparison and combination with other reports.

Prior to the exemplary simulation management processes of the flowchart100 concluding at block 136, the system 10 may conduct post processingfunctions at block 134. Post processing typically includes cleanupfeatures useful in freeing up file space and other memory needed forother applications. For instance, a user profile 41 may instruct thesystem 10 to delete all debugging files associated with a givensimulation at block 134 in response to a successful modeling sequence.

The flowchart 200 of FIG. 4 expands further upon processes associatedwith block 118 of FIG. 3. That is, the exemplary process steps 201-214are directed to monitoring the processing and generation of data used ina simulation management sequence in accordance with the principles ofthe present invention. Such generation/coordination processes areinitialized at block 201 of FIG. 4. As discussed above, suchinitialization may include or be preceded by retrieving applications andexecutables specified in a profile script.

At block 202 of FIG. 4, the system 10 may conduct pre-processingfunctions, including generating package and other modeling data. Whilepre-processing and package generation is discussed below in detail inconnection with FIG. 5, the pre-processing feature of the embodimentshown in block 202 of FIG. 4 typically includes generation andprocessing of data that can be accomplished prior to assembling a modelat block 204. As discussed herein, only those processes required for agiven application need be activated/generated in accordance with theprinciples of the present invention. For example, package files do notneed to be generated or recalled for parts of the circuit 70 that do notimpact a given simulation application. Moreover, partially generateddata may be utilized by the system 10 where possible to quickenanalysis.

The system 10 may use the package files generated at block 202 togenerate a model at block 204. While generation of the model is thesubject of FIG. 6 as discussed below, for purposes of block 204 of FIG.4, the step may generally include the automatic stitching, formattingand other combination processes associated with assembling datanecessary for a simulation sequence.

After such assembly has been accomplished at block 204, the system 10may automatically submit applications for execution at block 206. Thesubmission may be in batch, where desired. As such, submission of theapplications may be coordinated by the sequencer program 47. Thesequencer program 47 may be utilized at block 210 where the presence ofdependent jobs is determined at block 208. A dependent job includes anapplication that is affected by the prior or parallel processing ofanother application. For instance, one application may have to completebefore another can be processed. The sequencer program 47 may thusmanage the sequence of submissions for jobs that require coordinatedtiming. One of skill in the art will appreciate that the sequencerprogram 47 of another embodiment that is consistent with the inventionmay additionally function to submit all applications for execution, evenwhere dependency is not an issue. The system 10 at block 214 of FIG. 4may then call any remaining scripts and/or complete execution of thesimulation.

FIG. 5 shows steps 231-266 that relate to and expand upon thepre-processing and package generation step 202 of FIG. 4. Moreparticularly, the exemplary method steps 231-266 of FIG. 5 areconfigured to automatically initiate generation of a package fileconfigured for selective combination with other package files 44. Thecombined package files may comprise a net file 58 as described herein. Apackage file for purposes of an embodiment of the present invention mayinclude a text file having data that relates to at least a portion of aelectrical circuit 70 to be analyzed. Part of that analysis may includereception at block 231 of a comprehensive design file 46 that definesthe electrical circuit 70. Namely, the design file 46 may comprise datadetailing the construction specifications of the design, and istypically generated using a design tool 60, such as a CAD tool. Thedesign file 46 may be retrieved from memory 29, generated at the clientcomputer 12, and/or be transmitted from a remote source at block 231 ofFIG. 5.

Program code 62 consistent with the invention may process the designfile 46 to generate parseable data files for use in generating a packagefile 44. Such data files may include logical data 48, physical data 50and electrical data 52. As shown in FIG. 5, the program code createsphysical data 50 at block 232, logical data 48 at block 234 andelectrical data 52 at block 236. Logical data 48 generally includes textdescribing relative component connectivity. For instance, an exemplarylogical file may identify that an expansion card 78 a couples to both abus 82 a and a microchip module 74 a. Physical data 50 typicallyincludes geometric coordinates describing the precise location ofcomponents within a design. Where applicable, such coordinates of thephysical data 50 may have three dimensions to account for semiconductorlayers.

Electrical data 52 regards electrical attributes associated withcomponents, wiring or other portions of a design 70 designated foranalysis. Such electrical attributes may include resistance,capacitance, inductance and/or dispersion loss characteristicsprogammatically associated with a designated component and/or section ofthe design 70. As such, electrical data 52 consistent with the inventionmay specify an appropriate semiconductor layer and/or type of acomponent. Designations of a component may be accomplished using eitheror both logical and physical nomenclature. For instance, an inductancevalue may be assigned to all components having a particularidentification. The electrical parameters/characteristics, themselves,may be contained in an electrical model 45 stored separately from theelectrical data 52. A suitable electrical model 45 may be invoked orotherwise referenced by pointers present in the electrical data 52. Inthis manner, parameters of the model 45 are automaticallyassociated/imputed with specified components and/or design 70 portionsduring simulation.

As such, electrical data 52 may programmatically link to preexistingelectrical models 45 having applicable electrical characteristics. Asshown in FIG. 5, program code 62 consistent with the invention maydetermine if a model 45 having desired resistive and other electricalcharacteristics already exists at block 242. Where such an existingmodel 45 is located, the user or the program code 62 may select thatmodel 45 at block 244 for assignment to a given package or portion of apackage file. Alternatively, where a satisfactory, preexisting model 45cannot be determined at block 242, then pertinent electrical parametersmay be input by a user or retrieved from storage at block 246. Programcode 62 may then process the input parameters to generate a newelectrical model 45 at block 248 having the desired characteristics. Ineither case, the electrical data 52 may eventually be augmented by,initialize, point to, or otherwise include pertinent electrical modeldata 45 as selected or created at blocks 244 or 248, respectively.

As shown in FIG. 5, the physical, logical and electrical data 48-52 maybe generated at blocks 232, 234 and 236, respectively. Generation forpurposes of embodiments of the present invention may include sampling orotherwise extracting the data 48-52 from the design file 46. Generationmay likewise include processing of the design file 46 in conjunctionwith user/stored input as accomplished by the program code 62. All ofthe data 48-52 is typically formatted for subsequent processing andstorage at blocks 232-236. One of skill in the art will recognize thatother types of data consistent with the invention may be alternativelyor additionally generated. Moreover, it should be appreciated that thedata may be stored in one or more files at blocks 238, 240 and 250. Somefiles may include more than one type of data 48-52 or redundantinformation where advantageous. In some contexts, however, separatestorage of the data at blocks 238, 240 and 250 may facilitate morefocused processing and modification. Separate storage may additionallypreserve the integrity of unaffected and separately stored data. Asdiscussed herein in greater detail, such a feature can furtherstreamline design changes by allowing a user to immediately reuseunaffected data, without having to regenerate it.

Program code 64 consistent with the invention receives the storedphysical, logical and electrical data 48-52 at block 252 of FIG. 5. Forinstance, the program code 64 may automatically extract data from presetfields of each stored datasource 48-52. Program code 64 consistent withanother embodiment of the invention may sample all or only those datafields needed in a particular analysis and/or package generationsession. The program code 64 may selectively sample from the stored data48-52 according to predetermined package generation instructions. Suchinstruction may come from a system configuration file 57 and/or userinput. Thus, program code 64 at block 252 embodies another flexiblefeature that can reduce unnecessary memory and processing requirementsby filtering out superfluous data. Certain embodiment consistent withthe invention may further abstract data in a sequence that trackssimulation requirements. Such a feature may allow certain simulationprocesses to begin while package data compiles.

At block 254 program code 64 may combine or otherwise process the data48-52 sampled at block 252 to generate a package file 44. The resultantpackage file 44 may comprise a single text file having necessarylogical, physical and/or electrical data. By virtue of its discrete sizeand its selective inclusion of all necessary data, the package file 44at block 254 may present a manageable bundle of data that retains enoughdata to support an independent simulation. A suitable package file 44 ofanother environment may include just enough data to support a simulationwhen combined with other package files 44 containing complementarymodeling, stitching or other simulation data. Of note, informationcontained within the package file 44 includes at least one referenceconnection. An exemplary reference connection will typically comprise ageometric coordinate, such as may be included within the physical data50. For instance, a opportunistic reference connection includes a pinconnection 73 a used to interconnect components. One of skill in theart, however, will appreciate that other data, to include logical data48, may further comprise suitable reference connections. The referenceconnection of each package file is configured to correlate to arespective reference connection of one or more other package files.

The package file 44 may be respectively stored and output at blocks 256and 266 of FIG. 5. The stored package file 44 may be saved in connectionwith an identifier, such as a package name where advantageous. Thepackage identifier may be useful in combining packages into a net file,for instance, by providing part of a pointer address for retrieval intothe net file or an editing tool. Analogous to the individual storage ofthe data files 48-52 at blocks 238, 240 and 250, separate storage ofeach package file 44 preserves the integrity of the file 44 data.Individual storage at block 256 further facilitates net file 58stitching as discussed below. For example, where the same package isused in multiple simulations, the package can be reused withoutrequiring regeneration. Rather, only the package file(s) 44 or packagefile (stitched) configuration requiring change needs to be altered,preserving work achieved in the generation of other package files.

Where a given package file 44 does need to be altered for a givensimulation, the flexible, structured processes of the present inventionretain useful portions of the package file 44. For instance, a user mayselectively access only those aspects of the package file 44 requiringmodification. Blocks 258-262 of the embodiment of FIG. 5 show methodsteps suited to realize such versatility consistent with the presentinvention. More particularly, a user may desire at block 258 to changethe physical data 50 of a package. Physical data 50 previously saved aspart of the package file at block 256 may need to change for asubsequent simulation. Such a need may arise out of normal designoptimization processes. For instance, the user may substitute, deleteand/or add a component to a package file. Another user may reassign agiven component to another package file in order to streamline a givensimulation scenario. As such, the user may make the necessary change tothe stored physical data 50 at blocks 264 and 258. Of note, the logicaland electrical data 48, 52 of the package file as stored originally atblocks 240 and 250, respectively, may be reused with the updatedphysical data 50 at block 252.

Alternatively or additionally, the user may similarly modify existinglogical and electrical data 48, 52 of the package file 44 at blocks260-264. As such, the user may discretely make desired changes torespective portions of the text files without compromising data that theuser wishes to remain unchanged. While the sequence of steps shown inFIG. 5 may be advantageous for a given application, one of skill in theart will appreciate that embodiments consistent with the presentinvention may alter the order of any of the steps of the flowchart ofFIG. 5 or of those included herein. Moreover, a step may be added and/ordeleted in accordance with the underlying principles of the presentinvention.

The steps of FIG. 5 may be accomplished for a plurality of package filesas dictated by an applicable profile, net, simulation and/or design 70configuration. The plurality of package files may be stored within thedatabase 44 of FIG. 1 in such a manner as to be accessible by programcode 42 consistent with the invention. As such, program code 42 mayretrieve or otherwise receive package files at block 301 of FIG. 6. Theflowchart of FIG. 6 further includes exemplary process steps 301-324that further complement and/or comprise the model generation block 204of FIG. 4.

In the flowchart 300 of FIG. 6, each package file comprises a portion ofa (net) design 70 to be analyzed. Each package file may further compriseindependent logical, physical and electrical data 48-52, to include atleast one reference connection as discussed herein. For processingconsiderations, package data as shown at block 301 may include onlypartially generated package files. That is, the system 10 may initiallyabstract only that data that is necessary to begin a simulation process.This feature may further streamline simulation processes that otherwisemight be delayed.

A user may use a configuration file 57 formed as a function of aprofile, for instance, to stipulate which of the package files are to beincluded within a given simulation/net. An exemplary configuration file57 may include text having a programmatic instruction that directsprogram code 42 to selectively stitch packages. As such, the programcode 42 may receive and process the configuration file 57 at block 302of FIG. 6. The program code 42 may determine from the configuration file57 which of and how the package files are to be connected to form acomposite, net file.

The program code 42 then stitches designated package files togetherusing connective points of each package file. For instance, the programcode may link the package files using common connective pins. Pinmatching assignments may be predetermined per the configuration file 57.Alternatively, the program code 42 may automatically match connectivepoints for each package based on preset connection rules. Such rules mayaccount for geographic vicinity of connective points, component type,component material or virutually any other discemable feature ofrespective package files.

By virtue of the prior generation and separate storage of each packagefile in the database 44, stitching is accomplished without having tore-accomplish package creation. Furthermore, changes to theconfiguration file 57 made at block 322 may readily substitute, addand/or delete existing package files as required for subsequentsimulations.

More particularly, the system 10 may automatically retrieve thosepackage files from a database 44 at block 303 that are designated withinthe profile and configuration file 57. Program code 42 of one embodimentconsistent with the invention locates reference connections of each,retrieved package file at block 304. For instance, the program code 42may scan each package file for connector pins 73 a and 73 b. In thismanner, geometric coordinates for each connector pin 73 a and 73 b maybe determined. As discussed herein, suitable reference connections mayinclude other physical and/or logical information included within apackage file.

The program code 42 may correlate the located reference connections atblock 306. For example, the coordinates of the connector pins 73 a and73 b of the above example may be matched according to user input and/orpredetermined rules. Such rules may account for logical and/or physicaldata included within the configuration file 57 and/or program code 42,such as physical layering and logical connectivity. As such, a singlereference connection may link multiple, different package files asnecessary.

At block 308, the program code 42 may stitch the package files using thereference connections. For instance, the text of respective packagefiles may be arranged and augmented with connective, linking text withina generated net file. The resultant net file may then be output at block310 for subsequent formatting at block 312. One of skill in the art willappreciate that respective net files may be stitched using process stepssimilar to those described above in connection with stitching packagefiles.

Net files may be stored at block 314 of FIG. 6 within a database 58 forfuture use. Where useful, program code 42 may format the stored net fileaccording to modeling tool/simulator 68 specifications. Again, while thenet file need not include text, a text file may lend particularapplication to smooth formatting and conversion during subsequentprocessing. In any case, the simulator 68 may receive the net file alongwith electrical models at blocks 316 and 318, respectively. Electricalmodels are typically determined from the data contained within the netfile, or data otherwise derived from an input profile. As such,electrical models linked to text of the net file may be retrieved,sampled or otherwise applied at block 318. As discussed herein, thereferenced electrical models impute resistance and dispersion losscharacteristics to applicable portions of the net file.

Thus, the system 10 is in possession of or otherwise has access at block318 to at least most of all the data and programs needed to conduct agiven simulation. However, it is usually necessary for a user to runmultiple simulations using varying net files in order to optimize agiven design. Processes consistent with the present invention facilitatesuch analysis by allowing the user to make changes to the net file atblocks 320 and 322. Such changes may relate to package fileconfiguration and other modeling parameters known by those of skill inthe art. Where useful, textual changes may be made directly to theconfiguration file 57 at block 322. In this manner, a user maysubstitute, add and/or delete text from the net file as required forsubsequent simulations. Other changes may be accomplished by specifyinga new profile that is used to automatically generate a new configurationfile as discussed above. In either case, new net files may be realizedwithout having to re-accomplish other aspects of net file creation. Newnet files may be saved under new file names where desired.

While the present invention has been illustrated by a description ofvarious embodiments, and while these embodiments have been described inconsiderable detail, it is not the intention of the applicants torestrict or in any way limit the scope of the appended claims to suchdetail. For instance, while the exemplary sequence of steps shown inFIGS. 3-6 may have particular utility in certain contexts, it should beunderstood that the order of such steps may be rearranged and/ormodified to suit different design requirements. Additional advantagesand modifications will readily appear to those skilled in the art. Forinstance, while embodiments of the present invention analyze noise andtiming parameters with particular effectiveness, one of skill in the artwill appreciate that other design performance parameters may be analyzedusing methods that are consistent with the underlying principles of thepresent invention. Moreover, any of the programs, file or otherresources shown in FIG. 1 may be redistributed between local and remotecomputers per application specifications. Thus, the invention in itsbroader aspects is therefore not limited to the specific details,representative apparatus and method, and illustrative example shown anddescribed. Accordingly, departures may be made from such details withoutdeparting from the spirit or scope of the applicants' general inventiveconcept.

1. A method for managing a simulation involving an electrical design,comprising: receiving a modeling application that includes a pluralityof package files, wherein each package file is descriptive of a portionof the electrical design and defines a reference connection; selectivelyand automatically linking first and second package files of theplurality of package files by correlating respective referenceconnections of each of the first and second package files; andautomatically executing a simulation using the modeling application todetermine a performance characteristic of the electrical design.
 2. Themethod of claim 1, wherein executing the simulation farther includesautomatically monitoring for a status of the simulation.
 3. The methodof claim 2, further comprising automatically initiating a remedialaction in response to the status.
 4. The method of claim 1, whereinexecuting the simulation further includes coordinating submission of themodeling application for processing.
 5. The method of claim 1, whereinexecuting the simulation further includes conducting a pre-run check. 6.The method of claim 5, further comprising automatically performing aremedial action in response determining an error using the pre-runcheck.
 7. The method of claim 1, further comprising automaticallymaintaining a log file.
 8. The method of claim 1, further comprisinginterrupting at least a portion of the simulation in response to input.9. The method of claim 8, further comprising saving a state of theportion.
 10. The method of claim 1, further comprising automaticallyassembling output of the simulation.
 11. The method of claim 1, whereinlinking the package files includes selectively linking the package filesaccording to a profile.
 12. The method of claim 11, further comprisingautomatically generating the profile in response to input.
 13. Themethod of claim 1, further comprising automatically outputting a report.14. The method of claim 1, further comprising initiating post processesin response to the simulation ending.
 15. An apparatus, comprising: amemory; a database resident in the memory, the database storing aplurality of package files that comprise a modeling application, eachpackage file of the plurality of package files being descriptive of aportion of an electrical design and having a reference connectioncorrelating to a respective reference connection of another package fileof the plurality; and a program for selectively stitching first andsecond package files of the plurality of package files by correlatingthe respective reference connections of the first and second packagefiles; the program being further configured to execute a simulationusing the modeling application to determine a performance characteristicof the electrical design.
 16. The apparatus of claim 15, wherein theprogram initiates monitoring for a status of the simulation.
 17. Theapparatus of claim 16, wherein the program initiates a remedial actionin response to the status.
 18. The apparatus of claim 15, wherein theprogram initiates coordinating the submission of the modelingapplication for processing.
 19. The apparatus of claim 15, wherein theprogram initiates a pre-run check.
 20. The apparatus of claim 19,wherein the program initiates a remedial action in response todetermining an error using the pre-run check.
 21. The apparatus of claim20, wherein the program initiates selectively and logically linking thenet file with another net file.
 22. The apparatus of claim 15, whereinthe program maintains a log file.
 23. The apparatus of claim 15, whereinthe program initiates interrupting at least a portion of the simulationin response to input.
 24. The apparatus of claim 23, wherein the programinitiates saving a state of the portion.
 25. The apparatus of claim 15,wherein the program initiates assembling output of the simulation. 26.The apparatus of claim 15, wherein the program initiates selectivelinking of the package files according to a profile.
 27. The apparatusof claim 26, wherein the profile is generated in response to input. 28.The apparatus of claim 15, wherein the program initiates generating anoutput selected from a group consisting of at least one of: an analogwaveform, noise data and timing data.
 29. The apparatus of claim 15,wherein the program initiates post processes.
 30. A program product,comprising: a program configured to manage a simulation involving anelectrical design by selectively stitching first and second packagefiles of a plurality of package files that comprise a part of a modelingapplication, wherein each package file is descriptive of a portion ofthe electrical design; the program being further configured to execute asimulation using the modeling application to determine a performancecharacteristic of the electrical design; and a signal bearing mediumbearing the first program.
 31. The program product of claim 30, whereinthe signal bearing medium includes at least one of a recordable mediumand a transmission-type medium.